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SIMULTANEOUS SETUP OF PPP ON A UM AND RM INTERFACE 



BACKGROUND OF THE INVENTION 

5 L Field of the Invention 

The present invention relates to the field of wireless data services. More 
particularly, the present invention relates to a novel and improved method and 
system for setting up a Point-to-Point Protocol (PPP) link between a terminal 
equipment (TE2) and a base station /mobile switching center (BS/MSC) 
10 interworking function (IWC) through a wireless communication device (MT2). 

II. Description of Related Art 

Internetworking, i.e., the connection of individual local area networks 
(LANs), has rapidly become very popular. The infrastructure and associated 
15 protocols commonly referred to as the "Internet" have become well known and 
widely used. A well known protocol for providing access to the Internet is the 
Point-to-Point Protocol (PPP) which provides a standard method for 
transporting multi-protocol datagrams over point-to-point links, and is further 
described in Request for Comment (RFC) 1661, W. Simpson, Editor, dated July 
20 1994, herein incorporated by reference. 

PPP includes three main components: 

1 . a method of encapsulating multi-protocol datagrams; 

2. a Link Control Protocol (LCP) for establishing, configuring, 
and testing a data link connection; and 

25 3. a family of Network Control Protocols (NCPs) for establishing 

and configuring different network-layer protocols. 
FIG. 1 illustrates a high-level block diagram of a wireless data 
commimication system in which a mobile terminal (TE2 device) 102 
commimicates with an interworking function (IWF) 108 via a wireless 
30 communication system which includes a wireless communication device (MT2) 
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104 and Base Station/ Mobile Switching Center (BS/MSC) 106. As used herein 
MT2 may refer to either a phone or a combination of a phone and a PCM CIA 
card. In FIG. 1, the IWF 108 serves as the access point to the Internet. IWF 108 
is coupled to, and often co-located with BS/MSC 106, which may be a 
5 conventional wireless base station, as is known in the art. TE2 device 102 is 
coupled to MT2 device 104, which is in wireless commimication with BS/MSC 
106 and IWF 108. 

Many protocols exist which allow data communication between the TE2 
device 102 and the IWF 108. For example. Telecommunications Industry 
10 Association (TIA)/ Electronics Industries Association (EIA) Interim Standard IS- 
707.5, entitled ''Data Service Options for Wideband Spread Spectrum Systems: 
Packet Data Services,'' published February 1998, and herein incorporated by 
reference, defines requirements for support of packet data transmission 
capability on TTA/EIA IS-95 wideband spread spectrum systems, of which 
15 BS/MSC 106 and IWF 108 may be a part. IS-707.5 also provides the 
requirements for conunimication protocols on the links between the TE2 device 
102 and the MT2 device 104 (the interface), between the MT2 device 104 and 
the BS/MSC 106 (the interface), and between the BS/MSC 106 and the IWF 
108 (the L interface). 

Referring now to FIG. 2, a diagram of the protocol stacks in each entity of 
the IS-707.5 Relay Model is shown. FIG. 2 corresponds roughly to Figure 
1.4.2.2-1 of IS-707,5. At the far left of the figure is a protocol stack, shown in 
conventional vertical format, showing the protocol layers nmning on the TE2 
device 102 (e.g., the mobile terminal, laptop or palmtop computer). The TE2 
protocol stack is illustrated as being logically connected to the MT2 device 104 
protocol stack over the R^ interface. The MT2 device 104, is illustrated as being 
logically connected to the BS/MSC 106 protocol stack over the interface. 
The BS/MSC 106 protocol stack is, in turn, illustrated as being logically 
connected to the IWF 108 protocol stack over the L interface. 

As an example of the operation of the protocols of Fig. 2, the Point to 
Point Protocol (PPPr) protocol 206 encodes packets from the upper layer 
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protocols 202, 204 and transmits them across the R„ interface using the EIA-232 
protocol 208 to the EIA-232-compatible port on the MT2 device running the 
EIA-232 protocol 210. The EIA-232 protocol 210 on the MT2 device, receives the 
packets and passes them to the PPP^ protocol 205. The PPPr protocol 205 
5 unframes the packets encapsulated in PPP frames and typically, when a data 
connection is up, passes the packets to PPP^ protocol 215, which frames the 
packets in PPP frames for transmission to a PPP peer located in the IWF (108). 
The Radio Link Protocol (RLP) 212 and IS-95 protocol 214, both of which are 
well known in the art, are used to transmit the packets, which are encapsulated 

10 in PPP frames, to the BS/MSC 106 over the U„ interface. The RLP protocol 212 
is defined in IS-707.2, entitled "Data Service Options for Wideband Spread 
Spectrum Systems: Radio Link Protocol", February 1998, herein incorporated by 
reference, and the IS-95 protocol is defined in IS-95 mentioned above. A 
complementary RLP protocol 216 and IS-95 protocol 218 in the BS/MSC 106 

15 pass the packets to the relay layer protocol 220 for transmission across the L 
interface to relay layer protocol 228. PPP^ protocol 226 then unframes the 
received packets and passes them to the network layer protocols 225, which will 
either pass them to upper layer protocols 221 or forward them on to the 
Internet. 

20 As described in RFC 1661, the LCP Packets comprise a Configure- 

Request, a Configure-Ack, a Configure-Nak, and a Configure-Reject. The 
format of these packets is well known and described in RFC 1661. 

The Configure-Request packet is used to. negotiate configuration options. 
All configuration options are always negotiated simultaneously. 

25 The Configuration-Ack packet is transmitted if every configuration 

option in a received Configuration-Request packet is recognizable and all 

values are acceptable. 

The Configure-Nak packet is sent in response to a Configuration-Request 
packet when the requested configuration options are recognizable, but some of 
30 the values are not acceptable. The Options field of the Configure-Nak packet 
are filled only with the unacceptable configuration options from the Configure- 
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Request packet. Note that all configuration options are always Nak'd 
simultaneously. 

The Configure-Reject packet is sent when a received Configure-Request 
includes configuration options that are unrecognizable or are not acceptable for 
5 negotiation. The options field of the Configure-Reject contains only the 
unacceptable configuration options from the Configure-Request. 

The following comprises the well-known configuration options, 
described in RFC 1661, and defined for the PPP LCP protocol: 
1 . Maximum-Receive-Unit 
10 2. Authentication-Protocol 

3 . Quality-Protocol 

4. Magic-Number 

5. Protocol-Field-Compression 

6. Address-and-Control-Field-Compression 
15 7. ASYNC - Control Character 

Internet Protocol Control Protocol (IPCP) is a network control protocol 
responsible for configuring, enabling, and disabling Internet Protocol (IP) 
modules on both ends of the PPP link. IPCP is described in Request for 
Comment (RFC) 1332, "The PPP Internet Protocol Control Protocol (IPCP)", G. 
20 McGregor Merit, May, 1992, herein incorporated by reference. IPCP 
configuration options include: 

1. IP- Addresses; 

2. IP-Compression-Protocol; and 

3. IP-Address 

25 IPCP uses the same option negotiation mechanism as the Link Control 

Protocol (LCP). 

LCP and IPCP Configuration option negotiations occur separately for 
both the R„ interface and the U„ interface. That is, LCP or IPCP configuration 
option negotiation over one of the R^ and interfaces is separate from LCP or 
30 IPCP configuration option negotiation over the other of the R^ and U„ 
interfaces. Therefore, the wireless communication • device (MT2) must 
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separately negotiate configuration options over the R„, and U„ interfaces. 
Separate configuration option negotiating by the MT2 over the R„ and the U„ 
interfaces causes the configuration option negotiation mechanism of the MT2 
device to be unnecessarily complex and causes the configuration option 
5 negotiations on both interfaces to be unnecessarily long. 

SUMMARY OF THE INVENTION 

The present invention is a method and a wireless communication device 
(MT2) for simultaneously negotiating LCP or IPCP configuration options over 
both the R„ and the U„ interfaces. 

10 When the MT2 device receives either an LCP or an IPCP Configure- 

Request packet over one of the R„ and the U„ interfaces, the MT2 device parses 
the requested configuration options and determines whether the requested 
options are supported by the MT2 device. If the requested options are 
supported, the MT2 device saves a Configure-Request ID, included in the 

15 Configure-Request packet, and frames the Configure-Request packet in a PPP 
frame for transmission on the other of the R„ and the U„ interfaces. If any of the 
requested configuration options are not supported by the MT2 device, the MT2 
device creates a Configure-Reject packet, including the unsupported options, 
and frames the Configure-Reject packet in a PPP frame for transmission over 

20 the interface through which it received the Configure-Request packet, and the 
original request is discarded. 

Thus, a simple and quick mechanism for simultaneously negotiatiating 
configuration options on both of the R„ and the U„ interfaces is provided. 

BRIEF DESCRIPTION OF THE DRAWING 

25 These and other advantages will become more apparent from the 

detailed description of the preferred embodiments along with the following 
drawings: 
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Fig. 1 illustrates a high-level block diagram of a wireless data 
communication device in which a terminal device connects to a network, such 
as the Internet, via a wireless communication device; 

Fig. 2 is a diagram of the protocol stacks of each entity; 
5 Fig. 3 is a flowchart showing the processing that occurs when the MT2 

device receives a Configure-Request packet over the interface; 

Fig. 4 is a flowchart showing the processing that occurs when the MT2 
device receives a Configuration- Ack packet over the R^ interface; 

Fig. 5 is a flowchart showing the processing that occurs when the MT2 
10 device receives a Configure-Request packet over the interface; and 

Fig. 6 is a flowchart showing the processing that occurs when the MT2 
device receives a Configuration- Ack packet over the U„ interface. 



15 



DETAILED DESCRIPTION OF THE PREFERRED 

EMBODIMENTS 



As is known in the art, in order to establish communications over a 
point-to-point link. Link Control Protocol (LCP) packets for establishing, 
configuring and testing the data link connection must be exchanged over each 
PPP link, i.e., the R^ and interfaces. Any options not negotiated use a 
20 predefined default value, as specified by RFC 1661. 

Similarly, IPCP packets for negotiating and configuring IPCP 
configuration options must be exchanged over the R^ and interfaces. Any 
options not negotiated use a predefined default value, as specified by RFC 1332. 
As described in RFC 1661, the LCP Packets comprise a Configure- 
25 Request, a Configure-Ack, a Configure-Nak, and a Configure-Reject. The 
format of these packets is well known and described in RFC 1661. 

Because the mechanism for negotiating IPCP configuration options is 
identical to the mechanism for negotiating LCP configuration options, the 
following detailed description applies to both LCP and IPCP. 
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In a conventional system, configuration option negotiations occur 
separately for both the interface and the interface. As described in RFC 
1661 and RFC 1332, the Configure-Request packet contains a list of the options 
being requested and the Configuration- Ack packet contains a list of the options 
5 which the sender is acknowledging. 

Fig. 3 explains the processing which occurs when a LCP or a IPCP 
Configure-Request packet is received by the MT2 device over the R„ interface. 
Step S310 is performed to parse the configuration options requested in the 
Configure-Request packet. In step S320, each of the options are checked to 

10 determine whether they are supported by the MT2 device. 

If any of the options are not supported, step S330 is performed to create a 
Configure-Reject packet for the bad options. In step S340, the Configure- 
Request packet is discarded. In step S350, the Configure-Reject packet is sent to 
the PPP framer for the R„ interface, which will subsequently cause the 

15 Configure-Reject packet to be encapsulated in a PPP frame for transmission 
over the R^ interface. 

If Step S320 determines that all of the requested options are supported by 
the MT2 device, then step S360 is performed to save a Configure-Request ID, 
included in the Configure-Request packet. Step S370 is then performed to pass 

20 the Configure-Request packet to the PPP framer for encapsulation in a PPP 
frame for transmission over the interface. 

Fig. 4 explains the processing which occurs when a Configuration- Ack 
packet is received by the MT2 device over the R„ interface. In step S410, an ID 
in the Configuration-Ack packet is compared to the Configure-Request ID. If 

25 the IDs match, then step S420 is performed to save the configuration options 
included in the Configuration-Ack packet. Step S430 is performed to pass the 
Configuration-Ack packet to the PPP framer for the U„, interface, which will 
subsequently cause the Configuration-Ack packet to be encapsulated in a PPP 
frame and transmitted over the interface. 

30 If step S410 determines that the ID in the Configuration-Ack packet does 

not match the Configure-Request ID, then step S430 is performed to pass the 
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Configuration-Ack packet to the PPP framer for the interface, which will 
subsequently cause the Configuration-Ack packet to be encapsulated in a PPP 
^ frame and transmitted over the interface. In other words, the configuration 

options are not saved when the ID in the Configuration-Ack packet does not 
5 match the Configure-Request ID. 

Fig. 5 shows the processing that is performed when a Configure-Request 
packet is received over the interface. Figure 5 is analogous to Fig. 3, which 
shows the processing which occurs when a Configure-Request packet is 
received over the R^ interface. Step S510 is performed to parse the 
10 configuration options requested in the Configure-Request packet. In step S520, 
each of the options is checked to determine whether it is supported by the MT2 
device. 

If any of the options are not supported, step S530 is performed to create a 
Configure-Reject packet for the bad options. In step S540, the Configure- 
15 Request packet is discarded. In step S550, the Configure-Reject packet is sent to 
the PPP framer for the R^ interface, which will encapsulate the packet in a PPP 
frame for transmission on the R^ interface. 

If step S520 determines that all of the requested options are supported by 
the MT2 device, then step S560 is performed to save a Configure-Request ID, 
20 included in the Configure-Request packet. Step S570 is then performed to pass 
the Configure-Request packet to the PPP framer for the interface, which ' 
encapsulates the packet in a PPP frame for transmission over the interface. 

Fig. 6 shows the processing which occurs when a Configuration-Ack 
packet is received over the interface. Fig. 6 is analogous to Fig. 4 which 
25 shows the processing which occurs when a Configuration-Ack packet is 
received over the R^ interface. In step S610, an ID in the Configuration-Ack 
packet is compared to the Configure-Request ID. If the IDs match, then step 
S620 is performed to save the configuration options included in the 
Configuration-Ack packet. Step S630 is performed to pass the Configuration- 
30 Ack packet to the PPP framer for the U„ interface, which will subsequently 
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cause the Configuration-Ack packet to be encapsulated in a PPP frame and 
transmitted over the R„ interface. 
, If step S610 determines that the ID in the Configuration-Ack packet does 

not match theConfigure-Request ID, then step S630 is performed to pass the 
5 Configuration-Ack packet to the PPP framer for the R„ interface, which will 
subsequently cause the Configuration-Ack packet to be encapsulated in a PPP 
frame and transmitted over the R„ interface. In other words, the configuration 
options are not saved when the ID in the Configuration-Ack packet does not 
match the Configure-Request ID. 

10 Any other configuration negotiation packets received on one of the R„ 

and the U„ interfaces will be passed through the MT2 device and transmitted on 
the other of the R„ and the U„ interfaces. 

Fig. 7 shows examples of LCP configuration negotiations. At 70, the TE2 
device sends a LCP Configure-Request packet over the R„ interface to the MT2 

15 device. At 72, the MT2 receives the LCP Configure-Request packet, determines 
that the MT2 device does not support all the requested configuration options of 
the LCP Configure-Request packet and generates and sends a LCP Configure- 
Reject packet, indicating the bad options, over the R„ interface. 

At 74, the TE2 generates a LCP Configure-Request packet over the R„, 

20 interface. At 76, the MT2 device receives the LCP Configure-Request packet, 
parses the configuration options, determines that the configuration options are 
supported by the MT2 device, saves the Configure-Request ID from the LCP 
Configure-Request packet, frames the LCP Configure-Request packet in a PPP 
frame and transmits the PPP frame over the U„ interface. At 78, the IWF 

25 analyzes the LCP Configure-Request packet, determines that some of the 
requested options are bad, and sends a LCP Configure-Reject packet, including 
the bad options to the MT2 device over the U„ interface. At 80, the MT2 device 
receives the LCP Configure-Reject packet, determines that the received packet is 
neither a LCP Configure-Request packet nor a LCP Corifiguration-Ack packet 

30 and the MT2 device transmits the LCP Configure-Reject packet over the R„ 
interface to the TE2 device. 
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At 82, the TE2 device generates a LCP Configure Request packet over the 
interface to the MT2 device. At 84, the MT2 device parses the configuration 
options included in the LCP Configure-Request packet, determines that the 
MT2 device supports all configuration options, encapsulates the LCP 
5 Configure-Request packet in a PPP frame, and transmits the PPP frame over the 
U„ interface to the IWF. At 86, the IWF determines that it v^ould prefer to 
negotiate other values of the requested options and the IWF generates and 
transmits a LCP Configure-Nak packet indicating the desired option values. At 
88, the MT2 receives the LCP Configure-Nak, determines that the received 
10 packet is neither a LCP Configure-Request packet nor a LCP Configuration-Ack 
packet and the MT2 device transmits the LCP Configure-Nak, encapsulated in a 
PPP frame, over the R^ interface to the TE2 device. 

The above examples of Fig. 7 use the PPP LCP protocol, hov^ever, the 
IPCP protocol may also be used because the configuration negotiation 
15 mechanism is identical to the LCP protocol. For example, a IPCP Configure- 
Request may be used in place of a LCP Configure-Request; a IPCP Configure- 
Reject may be used in place of a LCP Configure-Reject; a IPCP Configure-Nak 
may be used in place of a LCP Configure-Nak, . etc. 

One of ordinary skill in the art would also understand that any of the 
20 above mentioned LCP or IPCP configuration negotiation packets may be 
transmitted from either the R^ interface or the U„ interface. 

While this invention has been described in connection w^ith what is 
presently considered to be the preferred embodiment, it is to be understood 
that the invention is not limited to the disclosed embodiment, but on the 
25 contrary, is intended to cover various modifications and equivalent 
arrangements included within the spirit and scope of the appended claims. 

We claim as our invention: 
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CLAIMS 

1. A method of simultaneously establishing a PPP link between a 
2 wireless communication device and an interworking hinction (IWF) on a U„ 

interface, and between said wireless communication device and a TE2 device 
4 over a R„ interface, said method comprising: 

receiving, in said wireless communication device, a Configure-Request 
6 packet over said R„ interface; 

determiiiing whether all configuration options included in said 
8 Configure-Request packet are supported by said wireless communication 
device; 

10 creating and sending a Configure-Reject packet when said determining 

determines that at least one of said configuration options included in said 

12 Configure-Request packet is not supported by said wireless communication 
device; and 

14 framing said Configure-Request packet in a PPP frame and transmitting 

said PPP frame over said U„ interface, when said determining determines that 

16 all of said configuration optior« in said Configuration Request packet are 
supported. 

2. A method according to claim 1, further comprising: 

2 storing, in a memory, a Configure-Request ID, included in said 

Configure-Request packet, when said determining determines that all of said 
4 configuration options in said Configure-Request packet are supported. 

3. A method according to claim 1, further comprising: 

2 receiving a Configuration- Ack packet over said U„ interface; and 

framing said Configuration-Ack packet in said PPP frame and sending 
4 said PPP frame including said Configuration-Ack packet over said R„ interface. 
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4. A method according to claim 2, further comprising: 

2 receiving a Configuration- Ack packet over said interface; and 

framing said Configuration- Ack packet in said PPP frame and sending 
4 said PPP frame including said Configuration- Ack packet over said interface. 

5. A method according to claim 4, further comprising: 

2 determining whether an ID included in said Configuration- Ack packet 

matches said Configure-Request ID stored in said memory; and 

4 saving values of all options included in said Configuration-Ack packet 

when said determining determines that said ID in said Configuration-Ack 

6 packet matches said Configure-Request ID stored in said memory. 

6. A method of simultaneously establishing a PPP link between a 
2 wireless communication device and an interworking function (IWF) on a 

interface, and between said wireless communication device and a TE2 device 
4 over a interface, said method comprising: 

receiving, in said wireless communication device, a Configure-Request 
6 packet over said R^ interface; 

determining whether all configuration options included in said 
8 Configure-Request packet are supported by said wireless communication 
device; 

10 creating and sending a Configure-Reject packet when said determining 

determines that at least one of said configuration options included in said 
12 Configure-Request packet is not supported by said wireless communication 

device; 

14 storing, in a memory, a Configure-Request ID, included in said 

Configure-Request packet, when said determining determines that all of said 
16 configuration options in said Configure-Request packet are supported; 

framing said Configure-Request packet in a PPP frame and transmitting 
18 said PPP frame over said interface, when said determining determines that 
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all of said configuration options in said Configuration Request packet are 
20 supported; 

receiving a Configuration- Ack packet over said U„ interface; 
22 determining v^hether an ID included in said Configuration- Ack packet 

matches said Configure-Request ID stored in said memory; 
24 saving values of all options included in said Configuration-Ack packet 

when said determining determines that said ID in said Configuration-Ack 
26 packet matches said Configure-Request ID stored in said memory; and 

framing said Configuration-Ack packet in said PPP frame and sending 
28 said PPP frame including said Configuration-Ack packet over said R„ interface. 

7. A method of simultaneously establishing a PPP link between a 
2 wireless communication device and an interworking function (IWC) on a U„ 

interface, and between said wireless commimication device and a TE2 device 
4 over a R„ interface, said method comprising: 

receiving, in said wireless communication device, a Configure-Request 
6 packet over said U„ interface; 

determining whether all configuration options included in said 
8 Configure-Request packet are supported by said wireless communication 
device; 

10 creating and sending a Configure-Reject packet when said determining 

determirws that at least one of said configuration options included in said 
12 Configure-Request packet is not supported by said wireless communication 

device; and 

14 framing said Configure-Request packet in a PPP frame and transmitting 

said PPP frame over said R„ interface, when said determining determines that 

16 all of said configuration options in said Configuration Request packet are 
supported. 

8. A method according to claim 7, further comprising: 
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2 storing, in a memory, a Configure-Request ID, included in said 

Configure-Request packet, when said determining determines that all of said 
4 configuration options in said Configure-Request packet are supported. * 

9. A method according to claim 8, further comprising: 

2 receiving a Configuration- Ack packet over said interface; and 

framing said Configuration- Ack packet in said PPP frame and sending 
4 said PPP frame including said Configuration- Ack packet over said interface. 

10. A method according to claim 8, further comprising: 

2 receiving a Configuration- Ack packet over said R^ interface; and 

framing said Configuration-Ack packet in said PPP frame and sending 
4 said PPP frame including said Configuration-Ack packet over said interface. 

11. A method according to claim 10, further comprising: 

2 determining whether an ID included in said Configuration-Ack packet 

matches said Configure-Request ID; and 
4 saving values of all options included in said Configuration-Ack packet 

when said determining determines that said ID in said Configuration-Ack 
6 piacket matches said Configure-Request ID stored in said memory. 

12. A method of simultaneously establishing a PPP link between a 
2 wireless communication device and an interworking function (IWC) on a U„ 

interface, and between said wireless communication device and a TE2 device 
4 over a R^ interface, said method comprising: 

receiving, in said wireless communication device, a Configure-Request 
6 packet over said interface; 

determining whether all configuration options included in said 
8 Configure-Request packet are supported by said wireless communication 
device; 
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10 creating and sending a Configure-Reject packet when said determining 

determines that at least one of said configuration options included in said 

12 Configure-Request packet is not supported by said wireless communicatipn 
device; 

14 storing, in a memory, a Configure-Request ID, included in said 

Configure-Request packet, when said determining determines that all of said 

16 configuration options in said Configure-Request packet are supported; 

framing said Configure-Request packet in a PPP frame and transmitting 

18 said PPP frame over said R^ interface, when said determining determines that 
all of said configuration options in said Configuration Request packet are 

20 supported; 

receiving a Configuration- Ack packet over said R„ interface; 
22 determining whether an ID included in said Configuration- Ack packet 

matches said Configure-Request ID stored in said memory; 
24 saving values of all options included in said Configuration- Ack packet 

when said determining determines that said ID in said Configuration-Ack 
26 packet matches said Configure-Request ID stored in said memory; and 

framing said Configuration-Ack packet in said PPP frame and sending 
28 said PPP frame including said Configuration-Ack packet over said U„ interface, 

13. A wireless communication device capable of simultaneously 
2 establishing a PPP link to an interworking function (IWC) on a U„ interface, and 
to a TE2 device over a R^ interface, said wireless communication device 
4 comprising: 

means for receiving a Configure-Request packet over said R^ interface; 
6 means for determining whether all configuration options included in 

said Configure-Request packet are supported by said wireless communication 
8 device; 

means for creating and for sending a Configure-Reject packet when said 
10 determining means determines that at least one of said configuration options 
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included in said Configure-Request packet is not supported by said wireless 
12 communication device; and 

means for framing said Configure-Requesbpacket in a PPP frame and for 
14 transmitting said PPP frame over said interface, when said determining 

means determines that all of said configuration options in said Configuration 
1 6 Request packet are supported. 

14. A wireless communication device according to claim 13, further 
2 comprising: 

means for storing, in a memory, a Configure-Request ID, included in said 
4 Configure-Request packet, when said determining means determines that all of 
said configuration options in said Configure-Request packet are supported. 

15. A wireless communication device according to claim 13, further 
2 comprising: 

means for receiving a Configuration-Ack packet over said interface; 

4 and 

means for framing said Configuration-Ack packet in said PPP frame and 
6 for sending said PPP frame including said Configuration-Ack packet over said 
R^ interface. 

16. A wireless communication device according to claim 15, further 
2 comprising: 

means for receiving a Configuration-Ack packet over said interface; 

4 and 

means for framing said Configuration-Ack packet in said PPP frame and 
6 for sending said PPP frame including said Configuration-Ack packet over said 
R^ interface. 

17. A wireless communication device according to claim 16, further 

2 comprising: 
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means for determining whether an ID included in said Configuration- 
4 Ack packet matches said Configure-Request ID stored in said memory; and 

means for saving values of all options included in said Configuration- 
6 Ack packet when said determining determines that said ID in said 
Configuration-Ack packet matches said Configure-Request ID stored in said 
8 memory. 

18. A wireless communication device capable of simultaneously 
2 establishing a PPP link to an interworking function (IWC) on a interface, and 
to a TE2 device over a R„ interface, said wireless commionication device 
4 comprising: 

means for receiving a Configure-Request packet over said R„ interface; 
6 means for determining whether all configuration options included in 

said Configure-Request packet are supported by said wireless communication 
8 device; 

means for creating and for sending a Configure-Reject packet when said 
10 determining means determines that at least one of said configuration options 
included in said Configure-Request packet is not supported by said wireless 
12 communication device; 

means for storing, in a memory, a Configure-Request ID, included in said 
14 Configure-Request packet, when said determining means determines that all of 

said configuration options in said Configure-Request packet are supported; 
16 means for framing said Configure-Request packet in a PPP frame and for 

transmitting said PPP frame over said interface, when said determining 
18 means determines that all of said configuration options in said Configuration 

Request packet are supported; 
20 means for receiving a Configuration-Ack packet over said interface; 

means for determining whether an ID included in said Configuration- 
22 Ack packet matches said Configure-Request ID stored in said memory; 

means for saving values of all options included in said Configuration- 
24 Ack packet when said determining determines that said ID in said 
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Configuration-Ack packet matches said Configure-Request ID stored in said 
26 memory; and 

means for framing said Configuration-Ack packet in said PPP frame and 
28 for sending said PPP frame including said Configuration-Ack packet over said 
interface. 

19. A wireless communication device capable of simultaneously 
2 establishing a PPP link an interworking function (IWC) on a interface, and to 
a TE2 device over a R^ interface, said wireless communication device 
4 comprising: 

means for receiving a Configure-Request packet over said interface; 
6 means for determining whether all configuration options included in 

said Configure-Request packet are supported by said wireless communication 
8 device; 

means for creating and for sending a Configure-Reject packet when said 
10 determining means determines that at least one of said configuration options 
included in said Configure-Request packet is not supported by said wireless 
12 comimunication device; and 

means for framing said Configure-Request packet in a PPP frame and for 
14 transmitting said PPP frame over said R^ interface, when said determining 
determines that all of said configuration options in said Configuration Request 
16 packet are supported. 

20. A wireless communication device according to claim 19, further 
2 comprising: 

means for storing, in a memory, a Configure-Request ID, included in said 
4 Configure-Request packet, when said determining means determines that all of 
said configuration options in said Configure-Request packet are supported. 

21. A wireless communication device according to claim 20, further 
2 comprising: 
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means for receiving a Configuration- Ack packet over said interface; 

4 and 

means for framing said Configuration-Ack packet in said PPP frame and 
6 for sending said PPP frame including said Configuration- Ack packet over said 
U„ interface. 

22. A wireless communication device according to claim 20, further 
2 comprising: 

means for receiving a Configuration- Ack packet over said U„ interface; 

4 and 

means for framing said Configuration-Ack packet in said PPP frame and 
6 for sending said PPP frame including said Configuration-Ack packet over said 
R interface. 

zn 

23. A wireless communication device according to claim 22, further 
2 comprising: 

means for determining whether an ID included in said Configuration- 
4 Ack packet matches said Configure-Request ID stored in said memory; and 

means for saving values of all options included in said Configuration- 
6 Ack packet when said determining means determines that said ID in said 
Configuration-Ack packet matches said Configure-Request ID stored in said 
8 memory. 

24. A wireless communication device capable of simultaneously 
2 establishing a PPP link to an interworking function (IWC) on a interface, 

and to a TE2 device over a R„ interface, said wireless communication device 
4 comprising: 

means for receiving a Configure-Request packet over said interface; 
6 means for determining whether all configuration options included in 

said Configure-Request packet are supported by said wireless communication 
8 device; 
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means for creating and for sending a Configure-Reject packet when said 
10 determining means determines that at least one of said configuration options 
included in said Configure-Request packet is not supported by said wireless 
12 communication device; 

means for storing, in a memory, a Configure-Request ID, included in said 
14 Configure-Request packet, when said determining means determines that all of 

said configuration options in said Configure-Request packet are supported; 
16 means for framing said Configure-Request packet in a PPP frame and for 

transmitting said PPP frame over said R^ interface, when said determining 
18 means determines that all of said configuration options in said Configuration 

Request packet are supported; 
20 means for receiving a Configuration- Ack packet over said R^ interface; 

means for determining whether an ID included in said Configuration- 
22 Ack packet matches said Configure-Request ID stored in said memory; 

means for saving values of all options included in said Configuration- 
24 Ack packet when said determining means determines that said ID in said 
Configuration- Ack packet matches said Configure-Request ID stored in said 
26 memory; and 

means for framing said Configuration- Ack packet in said PPP frame and 
28 for sending said PPP frame including said Configuration- Ack packet over said 
U„ interface. 
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